Industrial control systems have enabled modern factories to become partially or completely automated in many circumstances. These systems generally include a plurality of Input and Output (I/O) modules that interface at a device level to switches, contactors, relays and solenoids along with analog control to provide more complex functions such as Proportional, Integral and Derivative (PID) control. Communications have also been integrated within the systems, whereby many industrial controllers can communicate via network technologies such as Ethernet, Control Net, Device Net or other network protocols and also communicate to higher level computing systems. Industrial controllers utilize the aforementioned technologies along with other technology to control multiple applications ranging from complex and highly distributed to more traditional and repetitious applications.
At the core of the industrial control system, is a logic processor such as a Programmable Logic Controller (PLC). Programmable Logic Controllers are programmed by systems designers to operate manufacturing processes via user-designed logic programs or user programs. The user programs are stored in memory and generally executed by the PLC in a sequential manner although instruction jumping, looping and interrupt routines, for example, are also common. Associated with the user program are a plurality of memory elements or variables that provide dynamics to PLC operations and programs. These variables can be user-defined and can be defined as bits, bytes, words, integers, floating point numbers, timers, counters and/or other data types to name but a few examples.
Various remote applications often attempt to update and/or acquire PLC information or related device information via a plurality of different, competing and often incompatible network technologies. One attempt to standardize these competing technologies has been provided by the OLE for Process Control (OPC) Foundation that is supported by many leading controls and software manufacturers. Thus, manufacturers that support such communications standards can develop modules that communicate with other controllers/modules and/or networks. In view of emerging communications standards such as OPC, common communications architectures have developed. These architectures generally include a processor or PLC communicating on a local or factory network in accordance with an associated manufacturer's proprietary communications protocol. If a subsequent communications is desired to another network (e.g., transfer data from the local network to another network), a communications module is generally coupled to the processor, wherein the proprietary protocol is converted or translated to a subsequent network protocol.
This type of architecture requires the processor or PLC to first gather local network data before transferring the data to the communications module for subsequent transfer to other networks. Unfortunately, including the PLC in the communications path can cause performance problems, increase system expenses, and increase the amount of time required to interface systems that are designed by different control manufacturers. One such problem relates to providing increased horsepower on the PLC to handle potential communications that may occur since the data to be acquired may originate from another network device rather than the PLC. In addition, bottlenecks may occur within the PLC since communications from the local network are routed though the PLC. If the PLC is operating a complex and/or tightly controlled process, system performance (e.g., program execution time) may suffer if communications are significantly increased through the PLC.